The present invention relates generally to computer network systems for building automation. More particularly, the invention relates to an object-oriented software architecture that is specially designed for supporting building automation applications using an application-centric model.
Building automation systems are becoming increasingly sophisticated. Building owners and building managers want the convenience of being able to operate and maintain a variety of different devices and systems from generic computer work stations or personal computers attached to a network that integrates all of the different systems. For example, a typical building automation environment might include such diverse systems as heating and cooling (HVAC), electronic entry systems, burglar alarm systems, sprinkler systems, lighting systems, and the like. Integrating all of these different systems under a single computer network has heretofore proven to be quite challenging; in part, because the individual components and subsystems were not originally designed to work with one another.
Complicating matters further, building owners and building managers also want systems that take advantage of the latest innovations in energy management, systems diagnostics, building operation report generation and ease of use. For example, utility companies now supply large customers with real-time pricing information that may be used in a properly integrated system to lower utility costs by shifting non-essential energy consuming devices to off-peak hours. Building owners and building managers who currently cannot take advantage of real-time pricing will want to add that capability to their system. Demand for new features such as this provides a continual pressure for building automation software to change.
From the system integrator's standpoint, providing building owners and building managers with the new features and capabilities has heretofore been difficult. The difficulty stems in part from the fact that traditional building automation systems are designed from a device-centric or controller-centric viewpoint. From this conventional viewpoint building automation systems are built, from the ground up, according to the specifications and requirements of the hardware systems and controllers (processors) that make up the system. Unfortunately, this device-centric approach ties the software system architecture to a particular hardware platform, making it very difficult to develop new software as new hardware platforms evolve.
Also, the device-centric approach makes it very difficult to quickly develop new application programs to meet the demands of increasingly more sophisticated building owners and building managers. To develop a new application program, such as an application program that will advantageously exploit real-time pricing, the system integrator or system developer traditionally would need to develop an entirely new system, from the ground up, specifically incorporating all of the hardware dependencies, as needed, to implement the desired new functionality.
The present invention addresses these problems by providing a common object architecture that supports an application-centric approach. The common object architecture virtually eliminates the prior need to incorporate hardware dependencies into the system design. This results in a far more flexible system with significantly greater application longevity. The common object architecture of the invention encapsulates system properties that are less likely to change, such as properties dictated by the laws of physics or by human comfort considerations, into standard objects that more complex applications are assembled from. For example, the system can assume that a temperature below a predetermined threshold (e.g., colder than the lowest recorded temperature in Antarctica) is not a naturally occurring phenomenon and may therefore be attributed to a system or sensor failure. A connection object serves as the glue that binds these standard objects together by integrating message passing among the standard objects in a way that allows both asynchronous and synchronous processes to coexist.
In addition to encapsulating physically static parameters, such as minimum temperatures, the common object model also virtually eliminates the need to custom design new user interfaces when new applications are developed. The standard objects are derived from a superclass that defines a commands component and a views component. All standard objects inherit from the superclass and thereby include these commands and views components. The commands component encapsulates information about what methods may be performed by the particular standard object. The views component similarly identifies what attributes or data the particular object is able to supply to another object or to the user interface. In effect, all standard objects are able to convey information about (a) what methods they can perform and (b) what information they can provide. Thus the standard objects are, themselves, responsible for knowing how its attributes (data) are stored and how those attributes can be displayed and externally manipulated.
For example, a temperature sensor object based on a standard object would be capable of conveying its usable precision and range to the user interface. This allows the user interface to be implemented as a generic browser or window in which all user-actuable commands may be based on the methods identified by the standard objects' commands components and in which the information displayed in the window is identified and formatted according to the information in the respective views components.
For a more complete understanding of the invention, its objects and advantages, reference may be had to the following specification and to the accompanying drawings.